Generic and extensible provider debug interface

ABSTRACT

Described are techniques for debugging code of a provider using a debug interface. The provider includes a first software layer providing common services and a second software layer including code modules each providing a set of customized services. The debug interface includes a first function interface for a first function having first code included in the first software layer and including a second function interface for a second function having second code included in the first software layer which provides for runtime transfer of control to code included in said second software layer. The first function is invoked to issue debug commands to debug code in the first software layer. The second function is invoked to issue debug commands to debug code in the second software layer. A client sends debug commands in accordance with the debug interface to a server including the provider.

BACKGROUND

1. Technical Field

This application relates to techniques used in connection withinterfaces defined for providing services, and more particularly inconnection with providing a debug interface in connection with aprovider.

2. Description of Related Art

Computer systems may include different resources used by one or morehost processors. Resources and host processors in a computer system maybe interconnected by one or more communication connections. Theseresources may include, for example, data storage devices such as thoseincluded in the data storage systems manufactured by EMC Corporation.These data storage systems may be coupled to one or more servers or hostprocessors and provide storage services to each host processor. Multipledata storage systems from one or more different vendors may be connectedand may provide common data storage for one or more host processors in acomputer system.

A host processor may perform a variety of data processing tasks andoperations using the data storage system. For example, a host processormay perform basic system I/O operations in connection with datarequests, such as data read and write operations.

Host processor systems may store and retrieve data using a storagedevice containing a plurality of host interface units, disk drives, anddisk interface units. The host systems access the storage device througha plurality of channels provided therewith. Host systems provide dataand access control information through the channels to the storagedevice and the storage device provides data to the host systems alsothrough the channels. The host systems do not address the disk drives ofthe storage device directly, but rather, access what appears to the hostsystems as a plurality of logical disk units. The logical disk units mayor may not correspond to the actual disk drives. Allowing multiple hostsystems to access the single storage device unit allows the host systemsto share data in the device. In order to facilitate sharing of the dataon the device, additional software on the data storage systems may alsobe used.

In connection with data storage systems, or more generally any type ofsystem acting as a server, techniques may be used in connection withdebugging code of the server. Server code may include many differententities such as components, programs or modules, where each such entitymay provide its own debug interface to be invoked by a debug client inconnection with debugging the particular entity's code. For example, afirst component may provide a first debug interface including a firstset of defined functions which are invoked when debugging the firstcomponent. The debug client uses the first set of defined functions whenissuing debug commands to the first component. A second differentcomponent may provide a second debug interface including a second set ofdefined functions which are invoked when debugging the second component.The debug client uses the second set of defined functions when issuingdebug commands to the second component. Thus, the first and second setsof defined functions may be different so that the debug client issuingdebug commands needs to be aware of, and use, the appropriate set offunctions of the various debug interfaces when debugging each component.As there are changes to the supported debug commands, the debuginterfaces are modified. For example, if a new debug command is addedfor use with the above-mentioned first component, a new function may beadded to the first set to support the new command thereby changing thefirst debug interface, or a defined interface of an existing functionmay be modified to support the new command thereby also changing thedebug interface.

SUMMARY OF THE INVENTION

In accordance with one aspect of the invention is a method of debuggingcode of a provider comprising: receiving a debug interface for aprovider included in a server, said provider including a first softwarelayer providing common services and a second software layer including aplurality of code modules wherein each of said plurality of code modulesprovides a set of customized services, said common services being usedin combination with the set of customized services provided by any ofsaid plurality of code modules, said debug interface including a firstfunction interface for a first function having first code included insaid first software layer and including a second function interface fora second function having second code included in said first softwarelayer which provides for runtime transfer of control to code included insaid second software layer, said first function being invoked to issueany of a first set of debug commands to debug code in the first softwarelayer and said second function being invoked to issue any of a secondset of debug commands to debug code in the second software layer,wherein said second function is a same function used to issue debugcommands to each of the plurality of code modules of the second softwarelayer; sending, by a client to said server, a first debug command usingsaid debug interface, wherein said first debug command is used to debugcode included in said second software layer and said first debug commandis sent to said server by said client calling said second function inaccordance with said second function interface; and performing firstprocessing on said server for processing said first debug command, saidfirst processing including: invoking said second function bytransferring runtime control to said second code of the first softwarelayer, wherein said second code then passes the first debug commandthrough to the second software layer by invoking third code in one ofthe plurality of code modules of the second software layer, said thirdcode performing second processing for the first debug command includingsyntactic processing and semantic processing interpreting said firstdebug command and performing an action based on semantics of said firstdebug command. The first function interface may include a firstparameter representing a debug command issued to debug code of the firstlayer. The first function interface may indicate that an invocation ofsaid first function optionally includes one or more additionalparameters representing parameters of a debug command represented as thefirst parameter in the invocation. The first layer may include code forprocessing each debug command in the first set of debug commands. Thesecond function interface may include a first parameter representing adebug command issued to debug code of the second layer. The secondfunction interface may indicate that an invocation of said secondfunction optionally includes one or more additional parametersrepresenting parameters of a debug command represented as the firstparameter in the invocation. The second layer may include code forprocessing each debug command in the second set of debug commands. Thesecond set of debug commands may be used to debug code in a first codemodule of the second layer and a third set of debug commands may be usedto debug code in a second code module of the second layer, a firstportion of debug commands in the second set not being included in thethird set whereby the first portion of debug commands may not berecognized by code of the second module as valid debug commands fordebugging code of the second code module. The second code passing thefirst debug command through to the second software layer may includesaid second code not performing syntactic or semantic processing of thefirst debug command prior to invoking said third code. The second layermay be a platform specific layer and each of the plurality of codemodules may provide a different set of platform specific services. Theplurality of code modules may provide sets of services for a pluralityof data storage system platforms. The server may be included in a datastorage system in accordance with one of the plurality of data storagesystem platforms providing data storage services to the client. Thecommon services may include services provided for use with each of theplurality of data storage system platforms. Each of the plurality ofcode modules may provide a set of services for a different one of theplurality of data storage system platforms wherein each of the pluralityof data storage system platforms varies with properties related to anyof hardware and software of a data storage system. A first of theplurality of data storage system platforms may provide block-basedstorage services in connection with data storage system management andconfiguration and a second of the plurality of data storage systemplatforms may provide file-based storage services in connection withdata storage system management and configuration. A first of theplurality of code modules may include code providing said block-basedservices and a second of the plurality of code modules may include codeproviding said file-based services. The common services of the firstlayer may include services used in connection with data storage systemmanagement across all the plurality of data storage system platforms.The provider may provider data storage management services to the clientand the client may be a host system providing a virtualized environmentand having a plurality of virtual machines executing on the host system.The plurality of virtual machines may have applications executingthereon which have application data stored on provisioned storage ofstorage devices of the data storage system. The provider may providedata storage management services to the client where the client may bean aggregator providing collective data storage management for aplurality of hosts. Each of the plurality of hosts may provide avirtualized environment and may have one or more virtual machinesexecuting on said each host. Each of the one or more virtual machinesmay have an application executing in the context of said each virtualmachine wherein the application has its application data stored onprovisioned storage of storage devices of the data storage system. Theprovider may provide data storage management services for use inconnection with data storage management and configuration in avirtualized environment whereby the data storage management andconfiguration may be performed for managing storage provisioned for useby a plurality of virtual machines hosting applications each havingapplication data stored on provisioned storage of storage devices of thedata storage system.

In accordance with another aspect of the invention is a computerreadable medium include code for debugging code of a provider, thecomputer readable medium comprising code for: receiving a debuginterface for a provider included in a server, said provider including afirst software layer providing common services and a second softwarelayer including a plurality of code modules wherein each of saidplurality of code modules provides a set of customized services, saidcommon services being used in combination with the set of customizedservices provided by any of said plurality of code modules, said debuginterface including a first function interface for a first functionhaving first code included in said first software layer and including asecond function interface for a second function having second codeincluded in said first software layer which provides for runtimetransfer of control to code included in said second software layer, saidfirst function being invoked to issue any of a first set of debugcommands to debug code in the first software layer and said secondfunction being invoked to issue any of a second set of debug commands todebug code in the second software layer; and sending, by a client tosaid server, a first debug command using said debug interface, whereinsaid first debug command is used to debug code included in a specificone of said first software layer or said second software layer, whereinif said specific one is said first software layer, said sending includesissuing a call to said first function, and if said specific one is saidsecond software layer, said sending includes issuing a call to saidsecond function.

In accordance with yet another aspect of the invention is a computerreadable medium comprising code stored thereon for debugging code of aprovider, the computer readable medium comprising code for: receiving adebug interface for a provider included in a server, said providerincluding a first software layer providing common services and a secondsoftware layer including a plurality of code modules wherein each ofsaid plurality of code modules provides a set of customized services,said common services being used in combination with the set ofcustomized services provided by any of said plurality of code modules,said debug interface including a first function interface for a firstfunction having first code included in said first software layer andincluding a second function interface for a second function havingsecond code included in said first software layer which provides forruntime transfer of control to code included in said second softwarelayer, said first function being invoked to issue any of a first set ofdebug commands to debug code in the first software layer and said secondfunction being invoked to issue any of a second set of debug commands todebug code in the second software layer, wherein said second function isa same function used to issue debug commands to each of the plurality ofcode modules of the second software layer; sending, by a client to saidserver, a first debug command using said debug interface, wherein saidfirst debug command is used to debug code included in said secondsoftware layer and said first debug command is sent to said server bysaid client calling said second function in accordance with said secondfunction interface; and performing first processing on said server forprocessing said first debug command, said first processing including:invoking said second function by transferring runtime control to saidsecond code of the first software layer, wherein said second code thenpasses the first debug command through to the second software layer byinvoking third code in one of the plurality of code modules of thesecond software layer, said third code performing second processing forthe first debug command including syntactic processing and semanticprocessing interpreting said first debug command and performing anaction based on semantics of said first debug command. The firstfunction interface may include a first parameter representing a debugcommand issued to debug code of the first layer. The first functioninterface may indicate that an invocation of said first functionoptionally includes one or more additional parameters representingparameters of a debug command represented as the first parameter in theinvocation. The first layer may include code for processing each debugcommand in the first set of debug commands.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of the present invention will become moreapparent from the following detailed description of exemplaryembodiments thereof taken in conjunction with the accompanying drawingsin which:

FIG. 1 is an example of an embodiment of a system that may utilize thetechniques described herein;

FIG. 2 is an example illustrating details of a data storage system inaccordance with techniques herein;

FIGS. 3, 4 and 6 are examples illustrating components that may beincluded in an embodiment in accordance with techniques herein; and

FIG. 5 is an example of a debug API (application programming interface)that may be used in an embodiment in accordance with techniques herein.

DETAILED DESCRIPTION OF EMBODIMENT(S)

Referring to FIG. 1, shown is an example of an embodiment of a systemthat may be used in connection with performing the techniques describedherein. The system 10 includes one or more data storage systems 12connected to server or host systems 14 a-14 n through communicationmedium 18. The system 10 also includes a management system 16 connectedto one or more data storage systems 12 through communication medium 2.In this embodiment of the system 10, the management system 16, and the Nservers or hosts 14 a-14 n may access the data storage systems 12, forexample, in performing input/output (I/O) operations, data requests, andother operations. The communication medium 18 may be any one or more ofa variety of networks or other type of communication connections asknown to those skilled in the art. Each of the communication mediums 18and 2 may be a network connection, bus, and/or other type of data link,such as a hardwire or other connections known in the art. For example,the communication medium 18 may be the Internet, an intranet, network orother wireless or other hardwired connection(s) by which the hostsystems 14 a-14 n may access and communicate with the data storagesystems 12, and may also communicate with other components (not shown)that may be included in the system 10. In one embodiment, thecommunication medium 2 may be a LAN connection and the communicationmedium 18 may be an iSCSI or fibre channel connection.

Each of the host systems 14 a-14 n and the data storage systems 12included in the system 10 may be connected to the communication medium18 by any one of a variety of connections as may be provided andsupported in accordance with the type of communication medium 18.Similarly, the management system 16 may be connected to thecommunication medium 2 by any one of variety of connections inaccordance with the type of communication medium 2. The processorsincluded in the host computer systems 14 a-14 n and management system 16may be any one of a variety of proprietary or commercially availablesingle or multi-processor system, such as an Intel-based processor, orother type of commercially available processor able to support trafficin accordance with each particular embodiment and application.

It should be noted that the particular examples of the hardware andsoftware that may be included in the data storage systems 12 aredescribed herein in more detail, and may vary with each particularembodiment. Each of the host computers 14 a-14 n, the management system16 and data storage systems may all be located at the same physicalsite, or, alternatively, may also be located in different physicallocations. In connection with communication mediums 18 and 2, a varietyof different communication protocols may be used such as SCSI, FibreChannel, iSCSI, and the like. Some or all of the connections by whichthe hosts, management system, and data storage system may be connectedto their respective communication medium may pass through othercommunication devices and/or switching equipment that may exist such asa phone line, a repeater, a multiplexer or even a satellite. In oneembodiment, the hosts may communicate with the data storage systems overan iSCSI or a Fibre Channel connection and the management system maycommunicate with the data storage systems over a separate networkconnection using TCP/IP. It should be noted that although FIG. 1illustrates communications between the hosts and data storage systemsbeing over a first connection, and communications between the managementsystem and the data storage systems being over a second differentconnection, an embodiment may also use the same connection. Theparticular type and number of connections may vary in accordance withparticulars of each embodiment.

Each of the host computer systems may perform different types of dataoperations in accordance with different types of tasks. In theembodiment of FIG. 1, any one of the host computers 14 a-14 n may issuea data request to the data storage systems 12 to perform a dataoperation. For example, an application executing on one of the hostcomputers 14 a-14 n may perform a read or write operation resulting inone or more data requests to the data storage systems 12.

The management system 16 may be used in connection with management ofthe data storage systems 12. The management system 16 may includehardware and/or software components. The management system 16 mayinclude one or more computer processors connected to one or more I/Odevices such as, for example, a display or other output device, and aninput device such as, for example, a keyboard, mouse, and the like. Adata storage system manager may, for example, view information about acurrent storage volume configuration on a display device of themanagement system 16, provision data storage system resources, and thelike.

In one embodiment, the data storage systems 12 may include one or moredata storage systems such as one or more of the data storage systems,such as data storage arrays, offered by EMC Corporation of Hopkinton,Mass. Each of the data storage systems may include one or more datastorage devices 13 a-13 n, such as disks. One or more data storagesystems may be manufactured by one or more different vendors. Each ofthe data storage systems included in 12 may be inter-connected (notshown). Additionally, the data storage systems may also be connected tothe host systems through any one or more communication connections thatmay vary with each particular embodiment and device in accordance withthe different protocols used in a particular embodiment. The type ofcommunication connection used may vary with certain system parametersand requirements, such as those related to bandwidth and throughputrequired in accordance with a rate of I/O requests as may be issued bythe host computer systems, for example, to the data storage systems 12.It should be noted that each of the data storage systems may operatestand-alone, or may also be included as part of a storage area network(SAN) that includes, for example, other components such as other datastorage systems. Each of the data storage systems may include aplurality of disk devices or volumes 13 a-13 n. The particular datastorage systems and examples as described herein for purposes ofillustration should not be construed as a limitation. Other types ofcommercially available data storage systems, as well as processors andhardware controlling access to these particular devices, may also beincluded in an embodiment.

In such an embodiment in which element 12 of FIG. 1 is implemented usingone or more data storage systems, each of the data storage systems mayinclude code thereon for performing the techniques as described herein.

Servers or host systems, such as 14 a-14 n, provide data and accesscontrol information through channels to the storage systems, and thestorage systems may also provide data to the host systems also throughthe channels. The host systems may not address the disk drives of thestorage systems directly, but rather access to data may be provided toone or more host systems from what the host systems view as a pluralityof logical devices or logical volumes (LVs). The LVs may or may notcorrespond to the actual disk drives. For example, one or more LVs mayreside on a single physical disk drive. Data in a single storage systemmay be accessed by multiple hosts allowing the hosts to share the dataresiding therein. An LV or LUN (logical unit number) may be used torefer to the foregoing logically defined devices or volumes.

Referring to FIG. 2, shown is an example of an embodiment of the datastorage system 12 that may be included in the system 10 of FIG. 1.Included in the data storage system 12 of FIG. 2 are one or more datastorage systems 20 a-20 n as may be manufactured by one or moredifferent vendors. Each of the data storage systems 20 a-20 n may be adata storage array inter-connected (not shown) to other data storagearray(s). Additionally, as noted above, the data storage systems mayalso be connected to the host systems through any one or morecommunication connections 31. In this example as described in moredetail in following paragraphs, reference is made to the more detailedview of element 20 a. It should be noted that a similar more detaileddescription may also apply to any one or more of the other elements,such as 20 n, but have been omitted for simplicity of explanation.

Each of the data storage systems, such as 20 a, may include a pluralityof storage devices such as disk devices or volumes included in anarrangement 24 consisting of n rows of disks or more generally, datastorage devices, 24 a-24 n. In this arrangement, each row of disks maybe connected to a disk adapter (“DA”) or director responsible for thebackend management of operations to and from a portion of the disks 24.In the system 20 a, a single DA, such as 23 a, may be responsible forthe management of a row of disks, such as row 24 a. In a data storagesystem such as by EMC Corporation, a backend DA may also be referred toas a disk controller. The DA may performed operations such as readingdata from, and writing data to, the physical devices which are servicedby the DA.

The system 20 a may also include one or more storage processors 27. Eachof the storage processors 27 may be CPU and an embodiment may includeany number of such processors. For example, the VNX™ data storage systemby EMC Corporation includes two storage processors. The system 20 a mayalso include one or more host adapters (“HAs”) or directors 21 a-21 n.Each of the HAs may be used to manage communications and data operationsbetween one or more host systems and the global memory. In anembodiment, the HA may be a Fibre Channel Adapter (FA) or other adapterwhich facilitates host communication. The HA communicates with acomponent of the host such as a host bus adapter (HBA). Generally,directors may also be characterized as the different adapters, such asHAs (including FAs), DAs RAs and the like, as described herein.Components of the data storage system, such as an HA, which maycommunicate with a host may also be referred to as front end components.Within the data storage system, components, which may be characterizedas backend components, communicate with a front end component. Anexample of a backend component is a DA. In connection with data storagesystems such as by EMC Corporation, various types of directors oradapters may be implemented as a processor, or, more generally, acomponent that includes the processor. Examples of directors are diskadapters (DAs), host adapters (HAs), and the like.

One or more internal logical communication paths may exist between theDAs, the RAs, the HAs, and the memory 26. An embodiment, for example,may use one or more internal busses and/or communication modules. Forexample, the global memory portion 25 b may be used to facilitate datatransfers and other communications between the DAs, HAs and RAs in adata storage system. In one embodiment, the DAs 23 a-23 n may performdata operations using a cache that may be included in the global memory25 b, for example, in communications with other disk adapters ordirectors, and other components of the system 20 a. The other portion 25a is that portion of memory that may be used in connection with otherdesignations that may vary in accordance with each embodiment.

The particular data storage system as described in this embodiment, or aparticular device thereof, such as a disk, should not be construed as alimitation. Other types of commercially available data storage systems,as well as processors and hardware controlling access to theseparticular devices, may also be included in an embodiment.

Also shown in the storage system 20 a is an RA or remote adapter 40. TheRA may be hardware including a processor used to facilitatecommunication between data storage systems, such as between two of thesame or different types of data storage systems.

In connection with description set forth herein, the host may becharacterized in one aspect as a client of the data storage systemhaving storage provisioned on the data storage system. In someembodiments, the data storage system may provide the host withblock-based storage services and host provisioned storage may beblock-based. In connection with block-based storage services provided tothe host, the provisioned storage of the data storage system may includeone or more LUNs that are accessible or visible to a host, or moregenerally any client of the data storage system, over one or more pathsbetween the client and data storage system. Each path may be defined asincluding two endpoints, a first on the client and a second on the datastorage system. The first endpoint on the client may be an initiatorport of a component such as an HBA of the host used in connection withcommunicating with the data storage system such as to send I/O requeststo store and/or retrieve data on provisioned devices of the data storagesystem. The second endpoint of the data storage system may be a targetport of the data storage system such as a port of an FA of the datastorage system used in connection with communicating with the client. Aclient may have access to one or more LUNs included in a defined storagegroup (SG). Each initiator port may be configured to have access to aset of one or more target ports of the data storage system through whichall LUNs of the single SG are accessible or visible. The foregoinginformation regarding defined paths, SG definitions, what LUNs and SGsare accessible over what paths, and the like, may be included in a datastorage system configuration or topology. Such topology may change overtime as changes are made to an existing data storage systemconfiguration, for example, by adding/removing hosts therebyadding/removing paths, adding/removing LUNs from existing SGs,adding/removing HBAs to existing hosts thereby adding/removing paths,and the like.

In some embodiments, the data storage system may provide a client withfile-based storage services. Such file-based storage services may beimplemented on top of more primitive or basic services such asblock-based as well as others. In this manner, storage of the datastorage system is presented to the client as a file system. The clientmay access managed storage entities which are file-based such as filesystems, and directories and files in a file system. Yet further, insome embodiment, the data storage system may provide a client withstorage services that may be based on a combination of both block-basedand file-based services (e.g., offering both file-level protocols (e.g.,such as NAS or network attached storage protocols) and block-levelprotocols (e.g., such a SAN storage area network protocols such as SCSI,Fibre Channel, iSCSI, and the like) from the same storage system.

In connection with a data storage system, system management may beperformed using a server, such as a data storage system managementservice of the data storage system, and a client, such as using clientmanagement software executing on a host or, more generally any suitablecomputer system. Generally, the client may issue requests to the serverfor information used in connection with data storage system management.Such information may relate to, for example, existing data storageconfiguration or topology, health and status information of data storagesystem components, and the like. Information regarding the data storagesystem configuration or topology may include, for example, identifyingall paths between a host and the data storage system over whichprovisioned storage is accessible or visible, and other configurationinformation that may vary with whether the client is provided withfile-based services and/or block-based services. For example, a clientprovided with block-based services in accordance with block-basedprotocols supported on a data storage system may be provided with datastorage configuration information such as identifying a particular hostinitiator port (e.g., of an HBA) and data storage system target port(e.g., of an FA of the data storage system) included in a path,identifying what one or more LUNs are accessible over one or more paths(if the client is provided with block-based services), identifying whatone or more LUNs are accessible from a particular host initiator port,identifying what data storage system target ports are accessible to ahost having one or more host initiator ports, identifying what hostinitiator ports may be used to access storage through a particular datastorage system target port, identifying what target initiator ports maybe used to access storage through a particular host initiator port,identifying paths that may be used to access a particular LUN,identifying storage characteristics for LUNs (e.g., capacity, amount ofconsumed storage containing data, amount of free storage available forstoring user data, RAID configuration), and the like. For a clientprovided with file-based services in accordance with file-basedprotocols, the client may be provided with data storage configurationinformation such as, for example, information identifying the filesystems and associated file system attributes, files and directories ina file system, file attribute information (e.g., owner, access controls,date of last access, date of last modification, files size, etc.),quotas as may be defined per user or owner specifying storage capacityconsumption limits for the user, storage capacity and usage as relatedto a file system or directory (e.g., what is the total storage capacityof a file system, how much of the storage is consumed, how much isfree), and the like.

The foregoing are some examples of data storage configurationinformation as may be stored on the data storage system about itsconfiguration. Such information may be provided to a client requestingsuch information in connection with data storage management. Forexample, data storage management software may execute on a host or othercomputer system, such as the management system 16 of FIG. 1 where suchsystems may generally function as a client making requests of the datastorage system as a server. The management information may be providedto the client for display such as in connection with viewing aspectsrelated to a current configuration of a data storage system. The clientmay request an initial set of information from and then performsubsequent requests at later points in time, for example, to obtaininformation regarding any updates to the existing topology orconfiguration. Such updates may include, for example, changes inconnection with health or status of an existing component of the datastorage system such as an indicator about whether a data storage systemport is operable/can be used access LUNs, and the like, as may vary withthe particular services (e.g., file-based and/or block-based) providedto a client.

Generally, the data storage system may include one or more providers inconnection with providing services to the client such as theabove-mentioned file-based and block-based services as well as others.In an embodiment in accordance with techniques herein, the code of suchproviders may be debugged by issuing debug commands in the form ofrequests from a client to the data storage system. What will now bedescribed is a generic and extensible debug interface for use with theproviders in order to debug code of the providers such as of the datastorage system. The client may execute code, such as code of a debuggeror using a script, which results in invocations of this debug API and tocode of the providers for the purpose of performing various operationsfor debugging provider code modules.

Referring to FIG. 3, shown is an example of components that may beincluded in a system in an embodiment in accordance with techniquesherein. The system 500 may include a client 502 which issues requestssuch as those that may include debug commands specified using the debugAPI described herein. The client 502 may communicate with a data storagesystem 540 that includes the components below the dashed line. The datastorage system 540 may include an authentication and security component504, protocol adapters 506, 508, request director 510, and providers512, 520. Although described elsewhere herein but not illustrated forsimplicity of FIG. 3, the data storage system 540 may include physicalstorage devices from which storage is provisioned for use by datastorage clients. Element 506 denotes a protocol adapter whereby theprotocol adapter converts or maps received messages from the client(based on the protocol used by the client) to one or more other messageshaving a protocol understood by the data storage system. In oneembodiment, the protocol adapter selected (e.g. one of 506, 508 withreference to FIG. 3) may be based on the particular protocol used by theclient. The request director 510 may then select the appropriateprovider 512, 520 based on the content of the request received from theclient. As an example, consider provider A 512 providing services to aparticular set of clients operating in accordance with a firstparticular client protocol. The client 502 may send XML-based messagesin accordance with the first client protocol using HTTP to the datastorage system including the components of FIG. 3. The authenticationand security component 504 may perform processing for client sessionauthentication and security such as, for example, based on account nameor user id and password. After successful authentication by component504, requests may be received at the data storage system 540 from theclient 502 based on the first client protocol such as noted above.Depending on the particular client protocol, one of the adapters 506,508 may be selected to further convert or map the client request inaccordance with a first protocol (e.g., the particular client'sprotocol) to one or more resulting requests in accordance with a secondtarget protocol understood by the data storage system. In connectionwith this example, the protocol adapter A 506 may be selected based onthe first client protocol. The resulting requests may be sent to arequest director 510 which provides for further forwarding the requeststo the appropriate provider which, in this example, is provider A 512providing services to clients sending requests to the data storagesystem 540 based on the first client protocol. As noted above, therequest director 510 may select an appropriate one of the providers 506,508 based on the content of the received client request.

Provider A 512 may include a common interface layer 514 which specifiesprovider A's defined interface. For example, provider A 512 may performone or more services or commands where each such service or command maybe identified by a defined API call to a particular method or functionwith, optionally, any one or more parameters. The common layer interface514 may be the mechanism by which such a defined interface is specifiedand then used by the request director 510 in connection with matching anAPI call in the client request to the appropriate provider. In theexample herein, the provider A 512 may include a common layer 516 andone or more platform specific modules included in a platform specificlayer 518. The common layer 516 may include a common set of defined APIsthat may be used in connection with performing data storage managementand configuration across multiple platforms. A data storage systemplatform may be generally defined as different hardware and/or softwareand associated functionality as may be included in a data storageenvironment of a data storage system to a client. Thus, a data storagesystem platform may vary due to differences related to software and/orhardware on a data storage system such as, for example, data storagesystem vendor, a particular type, model or family of data storage systemprovided by a vendor, storage services provided (e.g., file-based,block-based, or some combination), and the like. Therefore, the commonlayer 516 may be characterized as including a set of platformindependent functions (also referred to as “interfaces” or “services”)that may be used in connection with different types of data storagesystems and varying services as provided to the client for the differentdata storage system platforms (e.g., a block based storage, file baseddata storage system). The set of platform independent functions as maybe used in connection with data storage management and configurationwith techniques herein may include functionality, for example, forvalidating and storing client certificates, management of a secureconnection and session context, and management of an event queue andalarm queue (e.g., such as in connection with management andnotification of consumed storage in accordance with defined storagequotas whereby an indication may be fired in response to amounts ofconsumed storage approaching defined limits). Such platform independentfunctions are generally applicable for use in connection with datastorage management and configuration across multiple data storage systemplatforms (e.g., the same set of platform independent functions may beused on types of different data storage systems, may be used inconnection with data storage systems providing only file-based servicesand may also be used in connection with data storage systems providingonly block-based services, and the like).

The platform specific layer 518 may include one or more platformspecific modules whereby each such platform specific module may includea set of functions that are specific to some aspect of a data storagesystem platform such as, for example, applicable only to a particulartype of data storage system 540 and providing data storage managementand configuration functionality for this particular platform. Forexample, block-based storage services may be a first platform specificmodule of the platform specific layer 518 which includes functionalityfor use with data storage system management and configuration that isspecific to providing block-based storage services such as collectinginformation and performing operations regarding block-based entities(e.g., LUNs), transforming block storage objects into storage objectsthat may be processed by the common layer 516, reporting storage systeminformation (e.g., storage topology, configuration information)regarding configured LUNs, unprovisioned physical storage devices, andthe like. Such block based storage services provided by the firstplatform specific module may include support for storage management APIsthat may provide storage information such as a list of storage entities(e.g. LUNs) based on a type of a storage entity, details of storagetopology of the storage entities, storage properties for the storageentities, and events for reporting configuration changes. As anotherexample, the platform specific layer 518 may include a second platformspecific module which includes functionality specific to providingfile-based storage management and configuration services such ascollecting information and performing operations regarding file-basedentities (e.g., files, directories, file system(s)). The second platformspecific module may include support for storage management APIsproviding storage management information related to file-based storagemanagement as described herein. The foregoing first and second platformspecific modules may each be applicable to a different data storagesystem platform. For example, a first data storage system platform maybe for a first type of data storage system that only provides itsclients with block-based services and storage management in connectionwith such block-based entities. The above-mentioned first platformspecific module may be used to provide such platform specific servicesfor this first data storage system platform. A second data storagesystem platform may be for a second type of data storage system thatonly provides its clients with file-based services. The above-mentionedsecond platform specific module may be used to provide such platformspecific storage management services for this second data storage systemplatform.

Referring to FIG. 4, shown is an example 600 illustrating in more detailservices and modules that may be provided by the different layers of aprovider in an embodiment in accordance with techniques herein. Theexample 600 illustrates further detail regarding provider A 512 of FIG.3. The common layer 516 may provide common services 604 such asmentioned above and elsewhere herein. The platform specific layer 518may provide platform specific services such as mentioned above andelsewhere herein. The layer 518 may include a block services module 610and a file services module 620 that provide platform specific storagemanagement services depending on the particular data storage systemplatform for which the layer 518 is providing services. The blockservices module 610 may be the first platform specific module describedabove providing block-based storage services for data storage systemmanagement and configuration, and the file services module 620 may bethe second platform specific module described above providing file-basedstorage services for data storage system management and configuration.

Arrows 602 a-c illustrate possible runtime execution flows to the layersof the provider A 512 as illustrated in the example 600. Element 602 arepresents that a client request specifying a common services API of thecommon layer 516 may result in invocation of code only in the layer 516.Element 602 b represents that a client request specifying a blockservices API call of the platform specific layer 518 may result ininvocation of code in module 610 of the layer 518. Additionally, thecall for the block services may be forwarded by, or passed through, thecommon layer 516 rather than be directly forwarded to layer 518. Inother words, as represented by 602 b, code of module 610 is not directlyinvoked from a layer above the common layer 516. Rather, in oneembodiment described herein, the block services call results in firsttransferring control to first code in the common layer 516 whereby thefirst code in the common layer 516 then forwards or passes through thecall to the block services module 610 by further invoking second codefor the appropriate API of the block services module 610.

Element 602 c illustrates runtime transfer of control in connection witha file services-based API call in a manner similar to that as denotedfor 602 b. Element 602 c represents that a client request specifying afile services API call of the platform specific layer 518 may result ininvocation of code in module 620 of the layer 518. Additionally, thecall for the file services may be forwarded by, or passed through, thecommon layer 516 rather than be directly forwarded to layer 518. Inother words, as represented by 602 c, code of module 620 is not directlyinvoked from a layer above the common layer 516. Rather, in oneembodiment described herein, the file services API call results in firsttransferring control to first code in the common layer 516 whereby thefirst code in the common layer 516 then forwards or passes through thecall to the file services module 620 by further invoking second code forthe appropriate API of the file services module 620.

It should be noted that each of the platform specific services modules610 and 620 may be implemented as shared libraries of code, such as DLLs(dynamic link libraries) or other entities that may vary withembodiment. For a data storage system providing only block services,module 610 would be loaded on the data storage system for use withtechniques herein but not module 620. For a data storage systemproviding only file services, module 620 would be loaded on the datastorage system for use with techniques herein but not module 610. If adata storage system provided some portion of both block and fileservices as illustrated by code of 610 and 620, then yet a third modulemay be prepared as a shared library including appropriate code for suchservices and the third module would be loaded for use with techniquesherein (rather than the modules 610 and 620). Thus, generally, theplatform specific layer 518 may include one or modules where each suchmodule may be implemented as a separate library. A selected libraryincluding code of the appropriate platform specific module may be loadedbased on the particular data storage system platform being used inconnection with techniques herein.

In connection with an embodiment described herein, techniques may beutilized in connection with debugging code in the common layer 516 andalso in the product specific layer 518. As described above, the commonlayer 516 may be characterized as including services that may be used byany client when performing data storage system management for any datastorage system platform. The product specific layer 518 includes moduleswith different and varied functionality customized for performing datastorage management for the different products or platforms. The layer518 may include multiple such platform specific modules whereby eachsuch platform specific module includes specific or platform dependentfunctions or routines customized for the particular data storage systemplatform. As just described and illustrated in connection with FIG. 4,incoming calls at runtime to the provider A 512 may be received by thecommon layer 516. Additionally, if the call is to a platform specificmodule, the call typically passes through the common layer 516 to theplatform specific layer 518 whereby the incoming call at runtime isfirst received by the common layer 516 and then passed through to theproduct specific layer 518.

In connection with an embodiment described herein, techniques may beutilized in connection with debugging code in the common layer 516 andalso in the product specific layer 518 as noted above. To this end, anembodiment may define a debug API including two methods—a first methodfor the common layer debug API for such calls which terminate at thecommon layer 516 and a second method for the platform specific layerdebug API for such calls which terminate at a module in the platformspecific layer 518.

The above-mentioned first method for the common layer debug API for suchcalls which terminate at the common layer 516 (e.g., such as illustratedby 602 a of FIG. 4) may have a defined API in the common layer interface514 represented as follows:

Common_debug (debug_command, debug_command_parameter1, . . . ,debug_command parameterN)

where:

“Common_debug” is the name of the first method having “debug_command” asits first parameter followed by one or more optional additional methodparameters.

“debug_command” is a string representing the debug command to beexecuted by code of the common layer 516.

“debug_command_parameter i” is a string denoting the “ith” parameterused by the debug command (e.g., denoted by “debug_command” in the firstmethod call). With reference to the above, let N represent the number ofoptional debug command parameters, where each ith additional debugparameter (i being an integer from 1 . . . N) is denoted as“command_parameter i”. The “ith” debug command parameter is the “i+1”parameter of the common_debug API method call.

Thus, the first method call (e.g., common_debug API method call) mayinclude at a minimum just a first parameter “debug_command” denoting adebug command to be executed with no debug command parameters.

The above-mentioned second method for the platform specific layer debugAPI for such calls which terminate at the product specific layer 518(e.g., such as illustrated by 602 b, 602 c of FIG. 4) may have a definedAPI in the common layer interface 514 represented as follows:

Platform_specific_debug (debug_command, debug_command_parameter1, . . ., debug command parameterN)

where:

“Platform_specific_debug” is the name of the second method having“debug_command” as its first parameter followed by one or more optionaladditional method parameters.

“debug_command” is a string representing the debug command to beexecuted by code of the platform specific layer 518.

“debug command_parameter i” is a string denoting the “ith” parameterused by the debug command (e.g., denoted by “debug_command” in thesecond method call). With reference to the above, let N represent thenumber of optional debug command parameters, where each ith additionaldebug parameter (i being an integer from 1 . . . N) is denoted as“command_parameter i”. The “ith” debug command parameter is the “i+1”parameter of the Platform_specific_debug API method call.

Thus, the second method call (e.g., Platform_specific_debug API methodcall) may include at a minimum just a first parameter “debug_command”denoting a debug command to be executed with no debug commandparameters.

It should be noted that an embodiment may alternatively represent thedebug commands and any debug command parameters in the first and/orsecond methods using constants, enumerated type values, or othersuitable values. Generally, the types associated with each parameter ofthe first and second methods may be generic such as all of type string,all of an integer type, and the like. The particular type selected forsuch method parameters does not indicate the type of the parameters suchas used in connection with semantic interpretation of the debug commandparameters. For example, an embodiment may encode each of the methodparameters as a string including those parameters which may representnumeric or integer type values for use with particular debug commands.As described in more detail elsewhere herein, processing may beperformed by code of the layers 516 and/or 518 (also referred to as thetarget layer elsewhere herein) which includes syntactic and semanticprocessing for a debug command used to debug code of that particularlayer. Such processing for the debug command may also include mappingthe generic type of a method parameter to another type suitable for usewith the debug command (e.g., mapping a method parameter of type stringhaving a value of “1” to a suitable integer type for use as an integervalue as a debug command parameter).

In connection with this second method, the code of the common layer 516may simply pass the second method parameters denoting the debug command(e.g., first parameter of the second method call) and any debug commandparameters (e.g., second and additional parameters of the second methodcall) to code of the product specific layer 518. For example, the codeof the common layer of the second method may invoke other code of theplatform specific layer passing the foregoing debug command and debugcommand parameters (specified as method call parameters for the secondmethod).

The above-mentioned two methods of the interface are extensible inseveral aspects. The debug command and debug parameters of the twomethods may denote any defined debug command and its optional debugparameters. Thus, as new debug commands are added, existing commandsremoved, or otherwise modified (e.g., add or change a debug commandparameter), for example, to the common layer, no change to the firstmethod, the common layer debug API, is needed. For new debug commandsadded to the common layer or for any changes made to common layer debugcommands, code may be added to the common layer to support such changes(e.g. for any new debug commands) and the client or other code (such asa script) performing the debug API call using the first method simplyadds appropriate first method calls with the correct one or more methodparameters for the new debug command. In a similar manner, as new debugcommands are added to the platform specific layer, no change to thesecond method, the product specific layer debug API, is needed. Code maybe added to the product specific layer to support the new debug commandand the client or other code (such as a script) making the debug APIcall using the second method simply adds appropriate second method callswith the correct one or more method parameters for the new debugcommand.

Additionally, as such debug commands are added to the product specificlayer (or other debug command modifications to remove or modify anexisting debug command are made with respect to debug commands of theproduct specific layer), no code changes in the common layer arenecessary to accommodate such changes such as for use of the new debugcommand in the product specific layer. This is due to the fact that eachparameter of the second method is not interpreted by the common layerand simply and transparently passed through to the platform specificlayer (e.g. the common layer code invokes code of the platform specificlayer passing the second method parameters—passing the debug command andany optional parameters for the platform specific layer).

The above-mentioned first and second methods may comprise the debug APIthereby providing a generic extensible debug interface for use inconnection with debugging where the invoked code that performs theprocessing for the requested debug operation is located either in thecommon layer 516 (e.g. invoke the above-mentioned first method fordebugging) or the platform specific layer 518 (e.g., invoke the secondabove-mentioned method for debugging). As noted above, if the code beingdebugged is located in the platform specific layer and the foregoingsecond method is used, the runtime call to the second method may befirst received by the common layer which then passes control andparameters to the appropriate platform specific layer module. Thus, inaccordance with techniques herein using the debug interface, a new debugcommand or other debug command change may be made with respect to theset of debug commands utilized for debugging the product specific layerwithout changing or impacting code in the common layer.

In an embodiment in accordance with techniques herein, a debug commandmay be processed by the particular layer including the code beingdebugged. In this case, for example, a debug command issued using thesecond method described herein to debug code of the platform specificlayer may be “passed through” to the platform specific layer by thecommon layer without the common layer performing syntactic or semanticprocessing of the debug command and its parameters, if any. Suchprocessing related to syntactic and/or semantic processing of the debugcommand may be performed by the platform specific layer. In thiscontext, the platform specific layer may be characterized as the targetor receiving endpoint layer of the debug command whereby the target orendpoint layer includes the code being debugged and therefore performsprocessing to interpret and execute the debug command. In other words,the target or endpoint layer may include code which processes the debugcommand and any parameters syntactically and semantically. As known inthe art, syntax generally refers to grammatical structure whereas theterm semantics refers to the meaning of the command and any parametersafter it has been recognized as a particular command by syntacticprocessing. An embodiment may use any suitable technique known in theart for syntactic processing and recognition of the debug command andany parameters such as, for example, using syntax rules, grammars,parsers, and the like. Once the particular debug command and anyparameters have been recognized by such syntactic processing, additionalprocessing may be performed based on the particular semantics of thedebug command. Such additional processing may including applyingsemantic rules to determine semantic validity of the debug command andapplying or implementing the debug command by performing one or moreactions. For example, semantic processing to determine semantic validityof a debug parameter may include testing the value of a parameter asbeing within a particular range if the parameter represents and integertype value. Applying or implementing the debug command semantics may bepart of executing the debug command. For example, a debug command todump or list a set of data items may include performing a first actionto retrieve current values for such data items and then a second actionto output the retrieved data item current values.

In a similar manner to that described above with respect to the platformspecific layer including the code to be debugged when the second methodis used, the common layer may also be characterized as the target orreceiving endpoint layer of the debug command when the first method isinvoked with a debug command whereby the common layer includes the codebeing debugged and therefore performs processing to interpret andexecute the debug command. In this manner, if there are changes madewith respect to debug commands used to debug code of a particular layer,the code of that layer only may be impacted without affecting otherlayers (or other modules of the same layer) of the provider and withoutrequiring modification to the debug API.

With reference now to FIG. 5, shown is an example illustrating the debugAPI as just described. In the example 700, the debug API in accordancewith techniques herein may include the first method 710 invoked whenissuing a debug command to the common layer of the provider. Element 710a denotes that the first method parameter is the debug commandoptionally followed by one or more debug command parameters 710 b. Thedebug API in accordance with techniques herein may include the secondmethod 720 invoked when issuing a debug command to the platform specificlayer of the provider. Element 720 a denotes that the second methodparameter is the debug command optionally followed by one or more debugcommand parameters 720 b. In connection with techniques herein, thedebug API may include one method or function used for issuing all debugcommands to a single layer. For example, the method of 710 may be usedto issue all debug commands directed to the common layer for debuggingcode of the common layer. The method of 720 may be used to issue alldebug commands directed to any module of the platform specific layer fordebugging code of the platform specific layer. Thus, the same singledebug API of 720 is used, for example, when issuing all desired debugcommands to debug code of module 610. Also the same single debug API of720 is used, for example, when issuing all desired debug commands todebug code of module 620. As there are changes to debug commands (e.g.,including any addition or deletion of debug commands) supported by aparticular platform specific module, the debug API does not change.Rather, for example, adding support for a new debug command means thatcode of the affected platform specific module is added for the newcommand (e.g., to recognize, interpret, and execute the new debugcommand) without modifying the debug API 720. The new debug command maybe specified as a new additional value as the first parameter of themethod 720.

In connection with techniques herein, it should be noted that it may notbe desirable to expose the platform specific module or layer interfacedirectly to the client. For example, the platform specific moduleinterfaces of the product specific layer may be proprietary. As such,the techniques herein provide for use of the above-mentioned secondmethod as the debug API when issuing debug commands to the productspecific layer whereby runtime control is indirectly transferred to theproduct specific layer through the common layer.

An embodiment may provide a different platform dependent module for eachdifferent type of data storage system where the type varies with aparticular storage system of a supported vendor. For example, EMCCorporation is a vendor of a variety of different data storage arrayssuch as the Symmetrix™ or VNX™ family of data storage systemsmanufactured by EMC Corporation. Thus, an embodiment may include a firstplatform specific module for use with a Symmetrix™ data storage arrayand a second platform specific module for use with a VNX™ data storagearray. As a further variation, depending on the particular configurationof a VNX™ data storage array, the VNX™ data storage array may beconfigured to provide block services only, file services only, or acombination of the foregoing to the client. To this end, an embodimentmay include three different platform specific modules for use with theforegoing three possible sets of file and/or block-based storageservices that vary with the particular platforms for the VNX™ datastorage array type. In connection with techniques herein, the samesecond method described herein for the platform specific layer debug APIfor such calls which terminate at the product specific layer 518 (e.g.,Platform_specific_debug (debug_command, debug_command_parameter1, . . ., command parameterN)) may be used for issuing debug commands to any ofthe foregoing platform specific modules.

More generally, the modules comprising the platform specific layer maybe customized for additional variations besides variations with respectto data storage system platform. More generally, the platform specificlayer may be further characterized as a lower layer of customized orspecialized provider modules that may be used with the techniques hereinto provide a generic debug interface (e.g., the above-mentioned secondmethod) that may be used with any such customized or specializedprovider module of the lower software layer (e.g., layer 518). Forexample, the particular customized specific module may also vary withthe particular client and debug commands that may be used by the clientto debug the customized specific module whereby the foreign specificmodule is “customized” or varies with respect to other modules of thelower layer independent of the particulars of the data storage systemplatform and data storage system environment. To further illustrate,consider a data storage array such as a Symmetrix™ data storage systemby EMC Corporation. For the same data storage system, a first client mayuse a first set of debug commands and a second client may use a seconddifferent set of debug commands having any of different command syntax,different debug command names, different parameters, etc, in comparisonto the first set. The first client may use debug commands that are afirst language such as English and the second client may use debugcommands in a second different language such as French, Spanish, German,Chinese, or any other language. As such, a different customized providermodule may be loaded for use with techniques herein depending on theparticular client. In connection with the foregoing as a variation, thefirst client may use debug commands in connection with debuggingblock-based storage system services for storage management andconfiguration (e.g., customized for block-based storage entities andproperties such as LUNs) since storage clients may not utilize anyfile-based protocols and the second client may use debug commands inconnection with debugging file-based storage system services for storagemanagement and configuration (e.g., customized for file-based storageentities and properties such as file systems, directories, files) sincestorage client may not utilize any block-based protocols. As such, adifferent customized provider module may be loaded for use withtechniques herein depending on the particular storage clients that mayuse a data storage system and the storage services used by such storageclients.

As yet another example, different software developments groups mayindependently develop provider software used in the data storage system.As a result, the different software development groups may haveindependently developed different sets of debug commands with differentsyntaxes, commands, and the like). In accordance with techniques herein,different customized provider modules may be included in the customizedlayer (e.g., generalization of the platform specific layer 518) tosupport the different sets of possible debug commands. For example, ifthere are two such software development groups that each have their ownset of debug commands, two customized modules may be included, one foreach set of debug commands whereby control may be transferred at runtimeto the appropriate customized module by the common layer using the debugAPI such as illustrated using the above-mentioned second method. Inconnection with such a generalization with respect to the platformspecific layer 518, layer 518 of FIG. 4 may more generally represent alower layer of customized or specific modules as described elsewhereherein.

To further illustrate use of the techniques herein such as using theabove-mentioned first and second methods, consider an exemplaryembodiment with reference to FIG. 4 in debugging code of a providerproviding data storage services in connection with data storagemanagement and configuration as described elsewhere herein in moredetail. The platform specific layer may include code modules as in FIG.4 for data storage system platform specific services whereby the commonlayer services may be used across or with data storage system platformsproviding block services or file services. A client may issue debugcommands to debug code of the provider where some commands may bedirected to debugging code of the common layer 516 and other commandsmay be directed to debugging code of one of the modules 610 or 620depending on the particular data storage system platform (e.g.,properties of the data storage system including the provider). In thisexample, assume the data storage system has a platform that onlyprovides block-based services so module 610 is loaded but not module620. The client may issue a first debug command that is a common layerdebug command to print or obtain a list of current sessions regardingconnected clients. To issue this first debug command, “LIST_SESSIONS”,the client may invoke the first method of the debug API (applicationprogramming interface) as follows with no parameters:

COMMON_DEBUG(LIST_SESSIONS)

The client may issue a second debug command (e.g., GET_SESSION_INFO) tothe common layer to list additional information or attributes about aparticular session (e.g., denoted as SESS_ID parameter) by invoking thefirst method as follows:

COMMON_DEBUG(GET_SESSION_INFO, SESS_ID)

The client may issue a third debug command (e.g., LIST_LUNS) to themodule 610 of the platform specific layer to obtain a list of LUNs andassociated LUN attributes as follows using the second method of thedebug API:

Platform_specific_debug (LIST LUNS)

with no debug parameters.

The client may issue a fourth debug command (e.g., GET_LUN_INFO) to themodule 610 of the platform specific layer to obtain a dump of attributeinformation for a particular LUN (e.g., LUNID) by issuing a call usingthe second method of the debug API as follows:

Platform_specific_debug (GET_LUN_INFO, LUNID)

The client may issue a fifth debug command (e.g., SET_LUN_INFO) to themodule 610 of the platform specific layer to set or modify attributeinformation for a particular LUN (e.g., LUNID) by issuing a call usingthe second method of the debug API as follows:

Platform_specific_debug (SET_LUN_INFO, LUNID, property1=value1)

where the debug command is SET_LUN_INFO, the first debug parameter isLUNID denoting the particular LUN having its attributes set or modified,the second debug parameter is an attribute or property-value pair,“property1=value1”, whereby “property1” denotes a particular LUNproperty or attribute that is set to the value “value1”. For this debugcommand, an attribute or property value pair may be specified as a debugparameter for each LUN property to be set.

The client may issue a sixth debug command (e.g., START_POLL) to themodule 610 of the platform specific layer to commence or start a pollingcycle such as to obtain a new or updated set of data storageconfiguration information by issuing a call using the second method ofthe debug API as follows with no debug parameters:

Platform_specific_debug (START_POLL).

Now, consider an alternate embodiment where module 620 is loaded for usein the platform specific layer rather than the module 610. In this case,the client may issue the same common layer debug commands such as theabove-mentioned first and second debug commands. However, rather thanissue the above-mentioned remaining third through sixth debug commands,the client may issue the following debug commands to the module 620 ofthe platform specific layer using the second method of the debug API:

DEBUG COMMAND A: Platform_specific_debug (LIST FILE SYSTEMS) with nodebug parameters to obtain a dump of all file systems and file systemlevel attribute information.

DEBUG COMMAND B:

Platform_specific_debug (GET_FILE_PPTY, C:/root.DIR1/FILE1, PARTIAL) toobtain a complete or partial list of file attributes where“GET_FILE_PPTY” is the debug command, “C:/root.DIR1/FILE1” identifiesthe file by specifying a complete path to the file, and “PARTIAL” is oneof a defined set of possible options which indicates that a partial listof file attributes are obtained. It should be noted that the seconddebug parameter as represented by the third method parameter may beeither PARTIAL as above or “ALL” to alternatively denote to obtain acomplete list of all file attributes for the specific file denoted bythe second debug parameter.

DEBUG COMMAND C: Platform_specific_debug (GET QUOTA LIMITS, USER1) toobtain any defined file system quota limits regarding storage that maybe consumed by the user “USER1”.

An embodiment in accordance with techniques herein may operate inaccordance with the Storage Management Initiative Specification (SMI-S),and Common Information Model (CIM) technologies which are examples ofspecifications and models well known by those skilled in the art. SMI-Sand CIM are widely used for managing storage devices and storageenvironments. CIM is described further below. The SMI-S is a standardmanagement interface that allows different classes of hardware andsoftware products to interoperate for monitoring and controllingresources. For example, the SMI-S permits storage management systems toidentify, classify, monitor, and control physical and logical resourcesin a SAN. The SMI-S is based on CIM, and Web-Based Enterprise Management(WBEM) architecture. CIM is a model for describing managementinformation, and WBEM is an architecture for using Internet technologiesto manage systems and networks. The SMI-S uses CIM to define objectsthat represent storage entities such as Logical Unit Numbers (LUNs),disks, storage subsystems, switches, and hosts. (In many, but not allcases, the term “volume” or “logical volume” is interchangeable with theterm “LUN”.) CIM also defines the associations that may or may not existbetween these objects, such as a disk being associated to a storagesubsystem because it physically resides in the storage subsystem.

The CIM objects mentioned above may be managed by a CIM object manager(CIMOM). A storage management software application can use a CIM clientto connect to a CIMOM, to retrieve information about the storageentities that the CIMOM manages, and also to perform activeconfiguration of the storage entities. Storage management software thatuses a CIM client may be called a CIM client application. For example,SMI-S describes how a current storage LUN is mapped. A CIM server is aCIMOM and a set of CIM providers. The SMI-S describes several methodsfor assigning a LUN from a disk storage system to a host, or for addinga LUN to a disk storage system.

With reference back to FIG. 3, the client 502 may be a CIM client for astorage management application that is a CIM server. The componentsillustrated as being included in the data storage system 540 may beincluded in the CIM server executing on the data storage system 504. Insuch an embodiment, the techniques herein may be further used inconnection with a provider of storage services for use in connectionwith management and configuration of data storage for virtualizedcomputing environments. Thus, the techniques herein may be used to debugcode of such a provider and a client may issue debug commands to theserver including the provider whereby such debug commands may be inaccordance with description herein such as, for example, using the debugAPI of FIG. 5. This is described in more detail below with reference toFIG. 6.

With reference now to FIG. 6, shown is another example an embodimentwhich may utilize techniques described herein. In the example 300,included are hosts 306 a, 306M, hosts 316 a, 316Y, client managementaggregators 310 a, 310 b, and data storage systems 302 a,302N. Initiatorports of the hosts are denoted as I1-I8. Target ports of the datastorage systems are denoted as P1-P8. Solid lines 334 a-334 h denotedata paths used for transmitting I/O operations or data requests andrequested data between connected components (e.g., between a host and adata storage system). Dashed lines 330 a-330 c, and 332 a-332 d denotemanagement or control paths between aggregator 310 a and hosts 306 a,306M, between aggregator 310 a and data storage system 302 a, betweenaggregator 310 b and hosts 316 a, 316Y, between aggregator 310 b anddata storage system 302 a and between aggregator 310 b and data storagesystem N. Such control paths may be used in connection with issuingcommands, and the like, for performing data storage management andconfiguration.

Each of the hosts and data storage systems may be as described elsewhereherein with the difference that the hosts 306 a, 306M and the hosts 316a,316Y may each not include client management software and each suchhost may also provide a virtualized environment including one or morevirtual machines (VMs) for executing applications on each such host.Each VM may have an application executing in the context of the VM wherethe application's data is stored on provisioned storage devices of oneor more of data storage systems 302 a,302N. Each of the hosts 306 a,306Mand the hosts 316 a,316Y may include a hypervisor that performs VMmanagement in connection with multiple VMs such as VMware ESX Server byVMware, Inc. Such a hypervisor, or more generally, VM manager, of eachhost having VMs executing therein may be installed and run directly onhost hardware without requiring an underlying operating system. Each ofthe VM managers may perform management of the underlying host's physicalresources for use among the multiple VMs that can run simultaneously.

Each of the client management aggregators 310 a, 312 b may function ashost management aggregators or centers providing data storage managementfor a plurality of hosts or, more generally clients of the data storagesystem. Each of the elements 310 a, 310 b may function as a clientobtaining data storage management and configuration from the use inmanaging storage for the virtualized environment. For example,aggregator 310 a may be used to perform data storage management andconfiguration for hosts 306 a,306M connected to 310 a over variousmanagement or control paths 330 a, 330 b. In a similar manner,aggregator 310 b may be used to perform data storage management andconfiguration for hosts 316 a,316Y connected to 310 b over variousmanagement or control paths 332 a, 332 b. Each of 310 a, 310 b mayinclude software thereon for performing such management for multiplehosts running virtualized environments as illustrated. For example, eachof 310 a, 310 b may include VMware vCenter™ Server software thatprovides for a central, scalable and extensible platform forvirtualization management of multiple virtualized hosts. In connectionwith techniques herein, each of the aggregators 310 a, 310 b mayinclude, respectively, client management software 312 a, 312 b. Thus,the aggregators 310 a, 310 b may function as an intermediate componentbetween the virtualized hosts and the data storage systems. In thismanner, aggregator 310 a may communicate with data storage system 302 aand hosts 306 a,306M where system 302 a has storage provisioned thereonfor use by the hosts 306 a,306M. Similarly, aggregator 310 b maycommunicate with data storage systems 302 a,302N and hosts 316 a, 316Ywhere systems 302 a, 302N have storage provisioned thereon for use bythe hosts 316 a,316Y and virtual machines and applications executingthereon.

Generally, each aggregator 310 a, 310 b may perform data storagemanagement for one or more hosts where each such host may have one ormore initiator ports included in data paths to one or more data storagesystems 302 a, 302N. In a manner similar to that as described elsewhereherein for a single host, an aggregator may perform management for oneor more hosts and may therefore include client management software toperform processing as described herein with a usage context representinga collective or aggregate usage context for the one or more hosts beingmanaged by the aggregator. Aggregator 310 a may define its usage contextas all objects related to a set of host initiators where the set is thecollective or aggregate of all initiator ports for hosts managed byaggregator 310 a. Aggregator 310 b may define its usage context as allobjects related to a set of host initiators where the set is thecollective or aggregate of all initiator ports for hosts managed byaggregator 310 b. To further illustrate, aggregator 310 a is performingdata storage configuration management for hosts 306 a, 306M and may havea usage context identifying initiator ports I1-I4. Aggregator 310 b isperforming data storage configuration management for hosts 316 a, 316Yand may have a usage context identifying initiator ports I5-I8. In thisexample, data storage system 302 a has a single client aggregator 310 aand data storage system 302N has two client aggregators 310 a, 310 b.Each aggregator may report data storage configuration information on thetopology and health from the context or viewpoint of the hosts saidaggregator is managing. Each of 310 a, 310 b may be a separate serversystem having a management console connected thereto upon whichinformation may be displayed based on each aggregator's usage context.Each aggregator 310 a, 310 b may use such a view or context forreporting storage provisioned for use by any of its managed hosts,reporting on a status or health of components in paths used to accessprovisioned storage, and the like. The number of hosts of eachaggregator 310 a, 310 b may generally be any number of hosts where eachsuch aggregator 310 a, 310 b may perform management for a differentnumber of such hosts. In connection with FIG. 6, and more generally anyof the examples and figures described herein, the particular number ofcomponents (e.g., number of hosts, number of aggregators, number of datastorage systems, etc.) is for purposes of illustration and should not beconstrued as applying a limit to an embodiment in accordance withtechniques herein.

As a further variation to the embodiment illustrated in FIG. 6, anembodiment may have hosts which do not provide virtualized environmentsand in such an embodiment each of 310 a, 310 b may be more generallydescribed as performing aggregate management of multiple hosts wheresuch hosts may or may not provide virtualized or other types ofenvironments. Furthermore, rather than have an aggregator 310 a, asingle host such as 316 a may provide a virtualized environment asdescribed herein whereby the host includes the client managementsoftware 312 a and communicates with any one or more of the data storagesystems providing storage and storage management services.

Thus, with reference to the particular example of FIG. 6, an embodimentin accordance with techniques herein may be used with a providerincluded in a data storage system where the provider provides storagemanagement services for only block-based services. In such anembodiment, the provider may be included as a component 303 a-303N inserver management software 304 a-304N on the data storage systems whereeach such provider 303 a-303N may include a common layer 516 and aplatform specific layer 518 having the block services module 610 loaded.Each of the elements 304 a-304N may include components such as thosedescribed herein, for example, the components of 540 in FIG. 3 and alsoin accordance with FIG. 4. Additionally, in accordance with techniquesherein, components 310 a, 310 b may function as clients in a mannersimilar to element 502 of FIG. 3 whereby components 310 a, 310 b mayissue debug commands to the provider to debug code of a provider 303a-303N providing such data storage management and configurationinformation to the clients. In this manner, a client, such as one of theaggregators 310 a, 310 b may issue debug commands to a provider, such as303 a, using the debug API as described herein whereby code of theprovider 303 a includes appropriate support for use with the debug APIas described herein. As will be appreciated by those skilled in the art,a client (such as component 310 a functioning as a client 502 of FIG. 3)issuing debug commands using the debug API as described herein fordebugging code of a provider of storage management services forvirtualized systems and environments does not have to actually host orinclude the client management software (e.g., 312 a, 312 b) or otherwisestore data on a data storage system. More generally, such a clientissuing debug commands in accordance with techniques herein may be anysuitable system to facilitate debugging code of the providers 303 a-303Nof storage management services for use in storage management forvirtualized systems and environments. Thus, in connection with FIG. 6and other exemplary embodiments herein, the client issuing the debugcommands in accordance with the debug API of FIG. 5 to a providerincluded in the data storage system may or may not also be a storageclient of the data storage system (e.g., the client issuing the debugcommands (debug client) may also be a “storage client” having its ownstorage provisioned in the data storage system, or may otherwise notalso be such a “storage client”).

Described herein are techniques that may be used in connection withproviding a debug interface or API for providers that allows debugsupport for both common layers and platform specific layers (or moregenerally customized modules as described herein) of the provider in away that may be extended without changing the debug Interface. Theinterface may be defined as described herein to include a debug commandwith an optional and variable number of debug command specificparameters. An interface in accordance with techniques herein providesfor flexibility and extensibility and also allows platform specificlayers to implement their own customized set of debug commands andparameters without requiring code changes to other provider layersbeyond the platform specific layer.

An embodiment may implement the techniques herein using code executed bya processor. For example, an embodiment may implement the techniquesherein using code which is executed by a processor of the data storagesystem, management system, or more generally, any computer system. Aswill be appreciated by those skilled in the art, the code may be storedon the data storage system on a computer-readable storage medium havingany one of a variety of different forms including volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information such as computer readableinstructions, data structures, program modules or other data.Computer-readable storage media includes, but is not limited to, RAM,ROM, EEPROM, flash memory or other memory technology, CD-ROM, (DVD) orother optical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other medium which canbe used to store the desired information and which can accessed by aprocessor.

While the invention has been disclosed in connection with preferredembodiments shown and described in detail, their modifications andimprovements thereon will become readily apparent to those skilled inthe art. Accordingly, the spirit and scope of the present inventionshould be limited only by the following claims.

What is claimed is:
 1. A method of debugging code of a providercomprising: receiving a debug interface for a provider included in aserver, said provider including a first software layer providing commonservices and a second software layer including a plurality of codemodules wherein each of said plurality of code modules provides a set ofcustomized services, said common services being used in combination withthe set of customized services provided by any of said plurality of codemodules, said debug interface including a first function interface for afirst function having first code included in said first software layerand including a second function interface for a second function havingsecond code included in said first software layer which provides forruntime transfer of control to code included in said second softwarelayer, said first function being invoked to issue any of a first set ofdebug commands to debug code in the first software layer and said secondfunction being invoked to issue any of a second set of debug commands todebug code in the second software layer, wherein said second function isa same function used to issue debug commands to each of the plurality ofcode modules of the second software layer; sending, by a client to saidserver, a first debug command using said debug interface, wherein saidfirst debug command is used to debug code included in said secondsoftware layer and said first debug command is sent to said server bysaid client calling said second function in accordance with said secondfunction interface; and performing first processing on said server forprocessing said first debug command, said first processing including:invoking said second function by transferring runtime control to saidsecond code of the first software layer, wherein said second code thenpasses the first debug command through to the second software layer byinvoking third code in one of the plurality of code modules of thesecond software layer, said third code performing second processing forthe first debug command including syntactic processing and semanticprocessing interpreting said first debug command and performing anaction based on semantics of said first debug command.
 2. The method ofclaim 1, wherein said first function interface includes a firstparameter representing a debug command issued to debug code of the firstlayer.
 3. The method of claim 2, wherein said first function interfaceindicates that an invocation of said first function optionally includesone or more additional parameters representing parameters of a debugcommand represented as the first parameter in the invocation.
 4. Themethod of claim 3, wherein the first layer includes code for processingeach debug command in the first set of debug commands.
 5. The method ofclaim 1, wherein said second function interface includes a firstparameter representing a debug command issued to debug code of thesecond layer.
 6. The method of claim 5, wherein said second functioninterface indicates that an invocation of said second functionoptionally includes one or more additional parameters representingparameters of a debug command represented as the first parameter in theinvocation.
 7. The method of claim 6, wherein the second layer includescode for processing each debug command in the second set of debugcommands.
 8. The method of claim 1, wherein the second set of debugcommands is used to debug code in a first code module of the secondlayer and a third set of debug commands is used to debug code in asecond code module of the second layer, a first portion of debugcommands in the second set not being included in the third set wherebythe first portion of debug commands are not recognized by code of thesecond code module as valid debug commands for debugging code of thesecond code module.
 9. The method of claim 1, wherein said second codepassing the first debug command through to the second software layerincludes said second code not performing syntactic or semanticprocessing of the first debug command prior to invoking said third code.10. The method of claim 1, wherein said second layer is a platformspecific layer and each of the plurality of code modules provides adifferent set of platform specific services.
 11. The method of claim 10,wherein the plurality of code modules provide sets of services for aplurality of data storage system platforms, said server is included in adata storage system in accordance with one of the plurality of datastorage system platforms providing data storage services to the client,and the common services includes services provided for use with each ofthe plurality of data storage system platforms, each of the plurality ofcode modules providing a set of services for a different one of theplurality of data storage system platforms wherein each of the pluralityof data storage system platforms varies with properties related to anyof hardware and software of a data storage system.
 12. The method ofclaim 11, wherein a first of the plurality of data storage systemplatforms provides block-based storage services in connection with datastorage system management and configuration and a second of theplurality of data storage system platforms provides file-based storageservices in connection with data storage system management andconfiguration, a first of the plurality of code modules including codeproviding said block-based services and a second of the plurality ofcode modules including code providing said file-based services, saidcommon services of the first layer including services used in connectionwith data storage system management across all the plurality of datastorage system platforms.
 13. The method of claim 12, wherein theprovider provides data storage management services to the client andwherein the client is a host system providing a virtualized environmentand having a plurality of virtual machines executing on the host system,the plurality of virtual machines having applications executing thereonwhich have application data stored on provisioned storage of storagedevices of the data storage system.
 14. The method of claim 12, whereinthe provider provides data storage management services to the client andwherein the client is an aggregator providing collective data storagemanagement for a plurality of hosts, each of the plurality of hostsproviding a virtualized environment and having one or more virtualmachines executing on said each host, each of the one or more virtualmachines having an application executing in a context of said eachvirtual machine wherein the application has its application data storedon provisioned storage of storage devices of the data storage system.15. The method of claim 12, wherein the provider provides data storagemanagement services for use in connection with data storage managementand configuration in a virtualized environment whereby the data storagemanagement and configuration is performed for managing storageprovisioned for use by a plurality of virtual machines hostingapplications each having application data stored on provisioned storageof storage devices of the data storage system.
 16. A non-transitorycomputer readable medium that includes code for debugging code of aprovider, the non-transitory computer readable medium comprising codefor: receiving a debug interface for a provider included in a server,said provider including a first software layer providing common servicesand a second software layer including a plurality of code moduleswherein each of said plurality of code modules provides a set ofcustomized services, said common services being used in combination withthe set of customized services provided by any of said plurality of codemodules, said debug interface including a first function interface for afirst function having first code included in said first software layerand including a second function interface for a second function havingsecond code included in said first software layer which provides forruntime transfer of control to code included in said second softwarelayer, said first function being invoked to issue any of a first set ofdebug commands to debug code in the first software layer and said secondfunction being invoked to issue any of a second set of debug commands todebug code in the second software layer; and sending, by a client tosaid server, a first debug command using said debug interface, whereinsaid first debug command is used to debug code included in a specificone of said first software layer or said second software layer, whereinif said specific one is said first software layer, said sending includesissuing a call to said first function, and if said specific one is saidsecond software layer, said sending includes issuing a call to saidsecond function.
 17. A non-transitory computer readable mediumcomprising code stored thereon for debugging code of a provider, thenon-transitory computer readable medium comprising code for: receiving adebug interface for a provider included in a server, said providerincluding a first software layer providing common services and a secondsoftware layer including a plurality of code modules wherein each ofsaid plurality of code modules provides a set of customized services,said common services being used in combination with the set ofcustomized services provided by any of said plurality of code modules,said debug interface including a first function interface for a firstfunction having first code included in said first software layer andincluding a second function interface for a second function havingsecond code included in said first software layer which provides forruntime transfer of control to code included in said second softwarelayer, said first function being invoked to issue any of a first set ofdebug commands to debug code in the first software layer and said secondfunction being invoked to issue any of a second set of debug commands todebug code in the second software layer, wherein said second function isa same function used to issue debug commands to each of the plurality ofcode modules of the second software layer; sending, by a client to saidserver, a first debug command using said debug interface, wherein saidfirst debug command is used to debug code included in said secondsoftware layer and said first debug command is sent to said server bysaid client calling said second function in accordance with said secondfunction interface; and performing first processing on said server forprocessing said first debug command, said first processing including:invoking said second function by transferring runtime control to saidsecond code of the first software layer, wherein said second code thenpasses the first debug command through to the second software layer byinvoking third code in one of the plurality of code modules of thesecond software layer, said third code performing second processing forthe first debug command including syntactic processing and semanticprocessing interpreting said first debug command and performing anaction based on semantics of said first debug command.
 18. Thenon-transitory computer readable medium of claim 17, wherein said firstfunction interface includes a first parameter representing a debugcommand issued to debug code of the first layer.
 19. The non-transitorycomputer readable medium of claim 18, wherein said first functioninterface indicates that an invocation of said first function optionallyincludes one or more additional parameters representing parameters of adebug command represented as the first parameter in the invocation. 20.The non-transitory computer readable medium of claim 19, wherein thefirst layer includes code for processing each debug command in the firstset of debug commands.